SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Incremental encoder</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Incremental encoder</span></span>

</h1>

</header>

<p>An <b>incremental encoder</b> is a linear or rotary electromechanical device that has two output <a href="Signal" title="Signal">signals</a>, <i>A</i> and <i>B</i>, which issue pulses when the device is moved.<sup id="cite_ref-sray_1-0" class="reference"><a href="#cite_note-sray-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> Together, the <i>A</i> and <i>B</i> signals indicate both the occurrence of and direction of movement. Many incremental encoders have an additional output signal, typically designated <i>index</i><sup id="cite_ref-craig_2-0" class="reference"><a href="#cite_note-craig-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> or <i>Z</i>,<sup id="cite_ref-epc_3-0" class="reference"><a href="#cite_note-epc-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> which indicates the encoder is located at a particular reference position. Also, some encoders provide a status output (typically designated <i>alarm</i>)<sup id="cite_ref-ics_4-0" class="reference"><a href="#cite_note-ics-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> that indicates internal fault conditions such as a <a href="Bearing_(mechanical)" title="Bearing (mechanical)">bearing</a> failure or sensor malfunction.

</p><p>Unlike an <a href="Absolute_encoder" class="mw-redirect" title="Absolute encoder">absolute encoder</a>, an incremental encoder does not indicate absolute position;<sup id="cite_ref-abs_5-0" class="reference"><a href="#cite_note-abs-5"><span class="cite-bracket">[</span>note 1<span class="cite-bracket">]</span></a></sup> it only reports changes in position and the corresponding direction of movement for each change. Consequently, to determine absolute position at any particular moment, it is necessary to send the encoder signals to an <i><a class="mw-selflink-fragment" href="#Incremental_encoder_interface">incremental encoder interface</a></i>, which in turn will "track" and report the encoder's absolute position.

</p><p>Incremental encoders report position increments nearly instantaneously, which allows them to monitor the movements of high speed mechanisms in <a href="Near_real-time" class="mw-redirect" title="Near real-time">near real-time</a>. Because of this, incremental encoders are commonly used in applications that require precise measurement and control of position and <a href="Velocity" title="Velocity">velocity</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Quadrature_outputs">Quadrature outputs</h2></div>

<p>

</p>

<p>An incremental encoder generates its <i>A</i> and <i>B</i> output signals using a quadrature encoding technique. When the encoder moves at a constant velocity, the <i>A</i> and <i>B</i> signals are <a href="Square_wave_(waveform)" title="Square wave (waveform)">square waves</a> with a 90° <a href="Phase_difference" class="mw-redirect" title="Phase difference">phase difference</a> between them, allowing detection of both movement and direction.<sup id="cite_ref-craig_2-1" class="reference"><a href="#cite_note-craig-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>At any particular time, the phase difference between the <i>A</i> and <i>B</i> signals will be positive or negative depending on the encoder's direction of movement. In the case of a rotary encoder, the phase difference is +90° for clockwise rotation and −90° for counter-clockwise rotation, or vice versa, depending on the device design.

</p><p><br>

</p>

<p>The frequency of the pulses on the <i>A</i> or <i>B</i> output is directly proportional to the encoder's velocity (rate of position change); higher frequencies indicate rapid movement, whereas lower frequencies indicate slower speeds.<sup id="cite_ref-sray_1-1" class="reference"><a href="#cite_note-sray-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> Static, unchanging signals are output on <i>A</i> and <i>B</i> when the encoder is motionless. In the case of a <a href="Rotary_encoder#Incremental_encoder" title="Rotary encoder">rotary encoder</a>, the frequency indicates the speed of the encoder's shaft rotation, and in <a href="Linear_encoder#Digital" title="Linear encoder">linear encoders</a> the frequency indicates the speed of linear traversal.

</p>

<dl><dt>Conceptual drawings of quadrature encoder sensing mechanisms</dt></dl>

<p>Quadrature encoder outputs can be produced by a quadrature-offset pattern read by aligned sensors (left diagram), or by a simple pattern read by offset sensors (right diagram).

</p>

<div class="gallerytext">Rotary encoder, with corresponding <i>A</i>/<i>B</i> signal states shown on the right as the shaft reverses.</div>

</li>

<div class="gallerytext">Linear encoder; <i>A</i>&<i>B</i> sensors are offset by 90° phase of the simple pattern, the <i>R</i> index signal indicates the encoder is located at its reference position. </div>

</li>

</ul>

<p><br>

</p>

<div class="mw-heading mw-heading3"><h3 id="Resolution">Resolution</h3></div>

<p>The resolution of an incremental encoder is a measure of the precision of the position information it produces. Encoder resolution is typically specified in terms of the number of <i>A</i> (or <i>B</i>) pulses per unit displacement or, equivalently, the number of <i>A</i> (or <i>B</i>) square wave cycles per unit displacement. In the case of rotary encoders, resolution is specified as the number of pulses per revolution (PPR) or cycles per revolution (CPR),<sup id="cite_ref-epc_3-1" class="reference"><a href="#cite_note-epc-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> whereas linear encoder resolution is typically specified as the number of pulses issued for a particular linear traversal distance (e.g., 1000 pulses per <a href="Millimeter" class="mw-redirect" title="Millimeter">mm</a>).

</p><p>This differs from the measurement resolution, which refers to the smallest change in position that the encoder can detect. Each <a href="Signal_edge" title="Signal edge">signal edge</a> on output <i>A</i> or <i>B</i> corresponds to a discrete position change. Because one full square-wave cycle on <i>A</i> (or <i>B</i>) includes four edges—rising <i>A</i>, rising <i>B</i>, falling <i>A</i>, and falling <i>B</i>—the measurement resolution is one-fourth of the distance represented by a full cycle. For example, a linear encoder with a resolution of 1000 pulses per millimeter has a per-cycle resolution of 1 μm (1 mm / 1000 cycles), yielding a measurement resolution of 250 nm (1 μm / 4).

</p>

<div class="mw-heading mw-heading3"><h3 id="Symmetry_and_phase">Symmetry and phase</h3></div>

<p>When moving at constant velocity, an ideal incremental encoder would output perfect square waves on <i>A</i> and <i>B</i> (i.e., the pulses would be exactly 180° wide and the <a href="Duty_cycle" title="Duty cycle"> duty cycle</a> would be 50%) with a phase difference of exactly 90° between <i>A</i> and <i>B</i> signals. In real encoders, however, due to sensor imperfections and speed variations, the pulse widths are never exactly 180° and the phase difference is never exactly 90°. Furthermore, the <i>A</i> and <i>B</i> pulse widths vary from one cycle to another (and from each other) and the phase difference varies at every <i>A</i> and <i>B</i> signal edge. Consequently, both the pulse width and phase difference will vary over a range of values.

</p><p>For any particular encoder, the pulse width and phase difference ranges are defined by "symmetry" and "phase" (or "phasing") specifications, respectively. For example, in the case of an encoder with symmetry specified as 180° ±25°, the width of every output pulse is guaranteed to be at least 155° and no more than 205°. Similarly, with phase specified as 90° ±20°, the phase difference at every <i>A</i> or <i>B</i> edge will be at least 70° and no more than 110°.

</p>

<div class="mw-heading mw-heading2"><h2 id="Signal_types">Signal types</h2></div>

<p>Incremental encoders employ various types of electronic circuits to drive (transmit) their output signals, and manufacturers often have the ability to build a particular encoder model with any of several driver types. Commonly available driver types include open collector, mechanical, push-pull and differential RS-422.

</p>

<div class="mw-heading mw-heading3"><h3 id="Open_collector">Open collector</h3></div>

<p><a href="Open_collector" title="Open collector">Open collector</a> drivers (using an <a href="NPN_transistor" class="mw-redirect" title="NPN transistor">NPN transistor</a> or open drain drivers using an <a href="NFET" class="mw-redirect" title="NFET">n-type MOSFET</a>) allow operation over a wide range of signal voltages and often can sink significant output current, making them useful for directly driving <a href="Current_loop" title="Current loop">current loops</a>, <a href="Opto-isolator" title="Opto-isolator">opto-isolators</a> and <a href="Fiber-optic_communication#Transmitters" title="Fiber-optic communication">fiber optic transmitters</a>.

</p><p>Because it cannot source current, the output of an open-collector driver must be connected to a positive DC voltage through a <a href="Pull-up_resistor" title="Pull-up resistor">pull-up resistor</a>. Some encoders provide an internal resistor for this purpose; others do not and thus require an external pull-up resistor. In the latter case, the resistor typically is located near the encoder interface to improve noise immunity.

</p><p>The encoder's high-level logic signal voltage is determined by the voltage applied to the pull-up resistor (<i>V<sub>OH</sub></i> in the schematic), whereas the low-level output current is determined by both the signal voltage and load resistance (including pull-up resistor). When the driver switches from the low to the high logic level, the load resistance and circuit capacitance act together to form a <a href="Low-pass_filter" title="Low-pass filter">low-pass filter</a>, which stretches (increases) the signal's <a href="Rise_time" title="Rise time">rise time</a> and thus limits its maximum switching frequency.

</p>

<div class="mw-heading mw-heading3"><h3 id="Mechanical">Mechanical</h3></div>

<p>Mechanical (or <i>contact</i>)<sup id="cite_ref-nasa_6-0" class="reference"><a href="#cite_note-nasa-6"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> incremental encoders use sliding <a href="Electrical_contacts" class="mw-redirect" title="Electrical contacts">electrical contacts</a> to directly generate the <i>A</i> and <i>B</i> output signals.<sup id="cite_ref-craig_2-2" class="reference"><a href="#cite_note-craig-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> Typically, the contacts are electrically connected to signal ground when closed so that the outputs will be "driven" low, effectively making them mechanical equivalents of open collector drivers and therefore subject to the same signal conditioning requirements (i.e. external pull-up resistor).

</p><p>The maximum output frequency is limited by the same factors that affect open-collector outputs, and further limited by <a href="Contact_bounce" class="mw-redirect" title="Contact bounce">contact bounce</a> (which must be filtered) and by the operating speed of the mechanical contacts, thus making these devices impractical for high frequency operation. Furthermore, the contacts experience mechanical wear under normal operation, which limits the <a href="Service_life" title="Service life">life</a> of these devices. On the other hand, mechanical encoders may be relatively inexpensive and have no internal, active electronics. These attributes make mechanical encoders a good fit for hand-operated controls (e.g. volume controls in <a href="Audio_equipment" title="Audio equipment">audio equipment</a> and voltage controls in bench <a href="Power_supplies" class="mw-redirect" title="Power supplies">power supplies</a>) and a variety of other low duty, low frequency applications.

</p>

<p><a href="Push-pull_output" class="mw-redirect" title="Push-pull output">Push-pull outputs</a> (e.g., <a href="Transistor%E2%80%93transistor_logic" title="Transistor–transistor logic">TTL</a>) typically are used for direct interface to logic circuitry. These are well-suited to applications in which the encoder and interface are located near each other (e.g., interconnected via printed circuit conductors or short, shielded cable runs) and powered from a common power supply, thus avoiding exposure to electric fields, ground loops and transmission line effects that might corrupt the signals and thereby disrupt position tracking, or worse, damage the encoder interface.

</p>

<div class="mw-heading mw-heading3"><h3 id="Differential_pair">Differential pair</h3></div>

<p>Differential <a href="RS-422" title="RS-422">RS-422</a> signaling is typically preferred when the encoder will output high frequencies or be located far away from the encoder interface,<sup id="cite_ref-nasa_6-1" class="reference"><a href="#cite_note-nasa-6"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-epc2_7-0" class="reference"><a href="#cite_note-epc2-7"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> or when the encoder signals may be subjected to electric fields or common-mode voltages,<sup id="cite_ref-nasa_6-2" class="reference"><a href="#cite_note-nasa-6"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> or when the interface must be able to detect connectivity problems between encoder and interface. Examples of this include <a href="Coordinate-measuring_machine" title="Coordinate-measuring machine">CMMs</a> and <a href="Numerical_control" class="mw-redirect" title="Numerical control">CNC</a> machinery, <a href="Industrial_robot" title="Industrial robot">industrial robotics</a>, factory automation, and <a href="Motion_platform" class="mw-redirect" title="Motion platform">motion platforms</a> used in aircraft and spacecraft simulators.

</p><p>When RS-422 outputs are employed, the encoder provides a differential conductor pair for every logic output; for example, "A" and "/A" are commonly used designations for the active-high and active-low differential pair comprising the encoder's <i>A</i> logic output. Consequently, the encoder interface must provide RS-422 line receivers to convert the incoming RS-422 pairs to single-ended logic.<sup id="cite_ref-nasa_6-3" class="reference"><a href="#cite_note-nasa-6"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Principal_applications">Principal applications</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Position_tracking">Position tracking</h3></div>

<p>Incremental encoders are commonly used to monitor the physical positions of mechanical devices. The incremental encoder is mechanically attached to the device to be monitored so that its output signals will change as the device moves. Example devices include the balls in mechanical computer mice and trackballs, control knobs in electronic equipment, and rotating shafts in radar antennas.

</p>

<div class="gallerytext">Trackballs and electromechanical computer mice employ two rotary incremental encoders to facilitate position tracking on two axes</div>

</li>

<div class="gallerytext">Electronic equipment controls are often implemented with a knob attached to a mechanical encoder (shown with detached knob)</div>

</li>

<div class="gallerytext">In commercial <a href="Marine_radar" title="Marine radar">marine radar</a> antennas, a rotary incremental encoder is typically attached to the rotating antenna shaft to monitor the antenna angle</div>

</li>

<div class="gallerytext">The location of a <a href="Pipeline_video_inspection" title="Pipeline video inspection">pipeline video inspection</a> tractor is typically monitored by a rotary incremental encoder attached to the tractor's cable reel</div>

</li>

</ul>

<p>An incremental encoder does not keep track of, nor do its outputs indicate the current encoder position; it only reports incremental changes in position.<sup id="cite_ref-epc_3-2" class="reference"><a href="#cite_note-epc-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> Consequently, to determine the encoder's position at any particular moment, it is necessary to provide external electronics which will "track" the position. This external circuitry, which is known as an incremental encoder interface, tracks position by counting incremental position changes.

</p><p>As it receives each report of incremental position change (indicated by a transition of the <i>A</i> or <i>B</i> signal), an encoder interface will take into account the phase relationship between <i>A</i> and <i>B</i> and, depending on the sign of the phase difference, count up or down. The cumulative "counts" value indicates the distance traveled since tracking began. This mechanism ensures accurate position tracking in bidirectional applications and, in unidirectional applications, prevents false counts that would otherwise result from vibration or mechanical dithering near an AB code transition.

</p>

<div class="mw-heading mw-heading4"><h4 id="Displacement_units">Displacement units</h4></div>

<p>Often the encoder counts must be expressed in units such as meters, miles or revolutions. In such cases, the counts are converted to the desired units by multiplying by the ratio of encoder displacement <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle D}">

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle D}</annotation>

</semantics>

</math></span><img src="./f34a0c600395e5d4345287e21fb26efd386990e6.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:1.924ex; height:2.176ex;" alt="{\displaystyle D}" loading="lazy"></span> per count <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle C}">

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle C}</annotation>

</semantics>

</math></span><img src="./4fc55753007cd3c18576f7933f6f089196732029.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.338ex; width:1.766ex; height:2.176ex;" alt="{\displaystyle C}" loading="lazy"></span>:

</p>

<mfrac>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle position=counts\times {\frac {D}{C}}}</annotation>

</semantics>

</math></span><img src="./6541da41bd2535013627e1e606d12d7550f9fb6d.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.005ex; margin-left: -0.089ex; width:23.932ex; height:5.343ex;" alt="{\displaystyle position=counts\times {\frac {D}{C}}}" loading="lazy"></span>.</span></dd></dl>

<p>Typically this calculation is performed by a computer which reads the counts from the incremental encoder interface. For example, in the case of a linear incremental encoder that produces 8000 counts per millimeter of travel, the position in millimeters is calculated as follows:

</p>

<mfrac>

<mtext>8000 counts</mtext>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle mm=counts\times {\frac {\text{1 mm}}{\text{8000 counts}}}}</annotation>

</semantics>

</math></span><img src="./433c80f7ad8f620f8a7a4bb86639025979077ed1.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -1.838ex; width:29.476ex; height:5.176ex;" alt="{\displaystyle mm=counts\times {\frac {\text{1 mm}}{\text{8000 counts}}}}" loading="lazy"></span>.</span></dd></dl>

<div class="mw-heading mw-heading4"><h4 id="Homing">Homing</h4></div>

<p>

In order for an incremental encoder interface to track and report absolute position, the encoder counts must be correlated to a reference position in the mechanical system to which the encoder is attached. This is commonly done by <i>homing</i> the system, which consists of moving the mechanical system (and encoder) until it aligns with a reference position, and then jamming<sup id="cite_ref-jam_8-0" class="reference"><a href="#cite_note-jam-8"><span class="cite-bracket">[</span>note 2<span class="cite-bracket">]</span></a></sup> the associated absolute position counts into the encoder interface's counter.

</p><p>A <a href="Proximity_sensor" title="Proximity sensor">proximity sensor</a> is built into some mechanical systems to facilitate homing, which outputs a signal when the mechanical system is in its "home" (reference) position. In such cases, the mechanical system is homed by moving it until the encoder interface receives the sensor signal, whereupon the corresponding position value is jammed into the position counter.

</p><p>In some rotating mechanical systems (e.g. rotating radar antennas), the "position" of interest is the rotational angle relative to a reference orientation. These typically employ a rotary incremental encoder that has an <i>index</i> (or <i>Z</i>) output signal. The <i>index</i> signal is asserted when the shaft is in its reference orientation, which causes the encoder interface to jam the reference angle into its position counter.

</p><p>Some incremental encoder applications lack reference position detectors and therefore must implement homing by other means. For example a computer, when using a mouse or trackball pointing device, typically will home the device by assuming a central, initial screen position upon <a href="Booting" title="Booting">booting</a>, and jam the corresponding counts into the X and Y position counters. In the case of panel encoders used as hand-operated controls (e.g., audio volume control), the initial position typically is retrieved from flash or other non-volatile memory upon power-up and jammed into the position counter, and upon power-down the current position count is saved to non-volatile memory to serve as the initial position for the next power-up.

</p>

<div class="mw-heading mw-heading3"><h3 id="Speed_measurement">Speed measurement</h3></div>

<p>Incremental encoders are commonly used to measure the speed of mechanical systems. This may be done for monitoring purposes or to provide feedback for <a href="Motion_control" title="Motion control">motion control</a>, or both.<sup id="cite_ref-nasa_6-4" class="reference"><a href="#cite_note-nasa-6"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> Widespread applications of this include speed control of <a href="Radar" title="Radar">radar</a> antenna rotation and <a href="Conveyor_system" title="Conveyor system">material conveyors</a>, and motion control in <a href="Robotics" title="Robotics">robotics</a>, <a href="Coordinate-measuring_machine" title="Coordinate-measuring machine">CMM</a> and <a href="Numerical_control" class="mw-redirect" title="Numerical control">CNC</a> machines.

</p><p>Incremental encoder interfaces are primarily concerned with tracking mechanical displacement and usually do not directly measure speed. Consequently, speed must be indirectly measured by taking the <a href="Derivative" title="Derivative">derivative</a> of the position with respect to time. The position signal is inherently <a href="Quantization_(signal_processing)" title="Quantization (signal processing)">quantized</a>, which poses challenges for taking the derivative due to quantization error, especially at low speeds.

</p><p>Encoder speed can be determined either by counting or by timing the encoder output pulses (or edges).<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> The resulting value indicates a frequency or period, respectively, from which speed can be calculated. The speed is proportional to frequency, and inversely proportional to period.

</p>

<div class="mw-heading mw-heading4"><h4 id="By_frequency">By frequency</h4></div>

<p>If the position signal is <a href="Sampling_(signal_processing)" title="Sampling (signal processing)">sampled</a> (a discrete time signal), the pulses (or pulse edges) are detected and counted by the interface, and speed is typically calculated by a computer which has read access to the interface. To do this, the computer reads the position counts <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle C_{0}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle C_{0}}</annotation>

</semantics>

</math></span><img src="./23da38e31194b9ae0524ec18c8489693f3be5389.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.716ex; height:2.509ex;" alt="{\displaystyle C_{0}}" loading="lazy"></span> from the interface at time <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{0}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{0}}</annotation>

</semantics>

</math></span><img src="./55b9e7d7b96196b5a6a26f4349caa3ac82fd67e3.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.412ex; height:2.509ex;" alt="{\displaystyle T_{0}}" loading="lazy"></span> and then, at some later time <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{1}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{1}}</annotation>

</semantics>

</math></span><img src="./2f304724948a3ef606c4a92459e22b87a954d993.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.412ex; height:2.509ex;" alt="{\displaystyle T_{1}}" loading="lazy"></span> reads the counts again to obtain <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle C_{1}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle C_{1}}</annotation>

</semantics>

</math></span><img src="./babf569931f1a7b5182b9bec51873c2f5692fbb8.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.716ex; height:2.509ex;" alt="{\displaystyle C_{1}}" loading="lazy"></span>. The average speed during the interval <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{0}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{0}}</annotation>

</semantics>

</math></span><img src="./55b9e7d7b96196b5a6a26f4349caa3ac82fd67e3.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.412ex; height:2.509ex;" alt="{\displaystyle T_{0}}" loading="lazy"></span> to <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{1}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{1}}</annotation>

</semantics>

</math></span><img src="./2f304724948a3ef606c4a92459e22b87a954d993.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.412ex; height:2.509ex;" alt="{\displaystyle T_{1}}" loading="lazy"></span> is then calculated:<sup id="cite_ref-craig_2-3" class="reference"><a href="#cite_note-craig-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<mfrac>

<mrow>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

</mrow>

<mrow>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

</mrow>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle speed={\frac {(C_{1}-C_{0})}{(T_{1}-T_{0})}}}</annotation>

</semantics>

</math></span><img src="./fa69fbbc4800acdc8c90f7ae158c37afcbb01ccb.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.671ex; width:19.659ex; height:6.509ex;" alt="{\displaystyle speed={\frac {(C_{1}-C_{0})}{(T_{1}-T_{0})}}}" loading="lazy"></span>.</span></dd></dl>

<p>The resulting speed value is expressed as counts per unit time (e.g., counts per second). In practice, however, it is often necessary to express the speed in standardized units such as meters per second, revolutions per minute (RPM), or miles per hour (MPH). In such cases, the software will take into account the relationship between counts and desired distance units, as well as the ratio of the sampling period to desired time units. For example, in the case of a rotary incremental encoder that produces 4096 counts per revolution, which is being read once per second, the software would compute RPM as follows:

</p>

<mfrac>

<mrow>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

</mrow>

<mtext>1 second</mtext>

</mfrac>

</mrow>

<mfrac>

<mtext>60 seconds</mtext>

<mtext>1 minute</mtext>

</mfrac>

</mrow>

<mfrac>

<mtext>1 revolution</mtext>

<mtext>4096 counts</mtext>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle RPM={\frac {(C_{1}-C_{0})}{\text{1 second}}}\times {\frac {\text{60 seconds}}{\text{1 minute}}}\times {\frac {\text{1 revolution}}{\text{4096 counts}}}}</annotation>

</semantics>

</math></span><img src="./58d7840fe4699db6f4a0480566c929a8dc17c1db.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.005ex; width:49.894ex; height:5.843ex;" alt="{\displaystyle RPM={\frac {(C_{1}-C_{0})}{\text{1 second}}}\times {\frac {\text{60 seconds}}{\text{1 minute}}}\times {\frac {\text{1 revolution}}{\text{4096 counts}}}}" loading="lazy"></span>.</span></dd></dl>

<p>When measuring speed this way, the measurement resolution is proportional to both the encoder resolution and the sampling period (the elapsed time between the two samples); measurement resolution will become higher as the sampling period increases.<sup id="cite_ref-craig_2-4" class="reference"><a href="#cite_note-craig-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="By_period">By period</h4></div>

<p>Alternatively, a speed measurement can be reported at each encoder output pulse by measuring the pulse width or period. When this method is used, measurements are triggered at specific positions instead of at specific times. The speed calculation is the same as shown above (counts / time), although in this case the measurement start and stop times (<span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{0}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{0}}</annotation>

</semantics>

</math></span><img src="./55b9e7d7b96196b5a6a26f4349caa3ac82fd67e3.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.671ex; width:2.412ex; height:2.509ex;" alt="{\displaystyle T_{0}}" loading="lazy"></span> and <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle T_{1}}">

<msub>

</mrow>

</msub>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle T_{1}}</annotation>

</semantics>

</p><p>This technique avoids position quantization error but introduces errors related to quantization of the time reference. Also, it is more sensitive to sensor non-idealities such as phase errors, symmetry errors, and variations in the transition locations from their nominal values.<sup id="cite_ref-petrella_10-0" class="reference"><a href="#cite_note-petrella-10"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Incremental_encoder_interface">Incremental encoder interface</h2></div>

<p>

</p>

<p>An <b>incremental encoder interface</b> is an electronic circuit that receives signals from an incremental encoder, processes the signals to produce absolute position and other information, and makes the resulting information available to external circuitry.

</p><p>Incremental encoder interfaces are implemented in a variety of ways, including as <a href="ASIC" class="mw-redirect" title="ASIC">ASICs</a>, as <a href="Semiconductor_intellectual_property_core" title="Semiconductor intellectual property core">IP blocks</a> within <a href="FPGA" class="mw-redirect" title="FPGA">FPGAs</a>, as dedicated peripheral interfaces in <a href="Microcontroller" title="Microcontroller">microcontrollers</a>, or as software (via <a href="Interrupts" class="mw-redirect" title="Interrupts">interrupts</a> or <a href="Polling_(computer_science)" title="Polling (computer science)">polling</a> <a href="GPIO" class="mw-redirect" title="GPIO">GPIOs</a>).

</p><p>Regardless of the implementation, the interface must sample the encoder's <i>A</i> and <i>B</i> output signals frequently enough to detect every AB state change before the next state change occurs. Upon detecting a state change, it will increment or decrement the position counts based on whether <i>A</i> leads or trails <i>B</i>. This is typically done by storing a copy of the previous AB state and, upon state change, using the current and previous AB states to determine movement direction.

</p>

<div class="mw-heading mw-heading3"><h3 id="Line_receivers">Line receivers</h3></div>

<p>Incremental encoder interfaces use various types of electronic circuits to receive encoder-generated signals. These line receivers serve as buffers to protect downstream interface circuitry and, in many cases, also provide signal conditioning functions.

</p>

<div class="mw-heading mw-heading4"><h4 id="Single-ended">Single-ended</h4></div>

<p>Incremental encoder interfaces typically employ <a href="Schmitt_trigger" title="Schmitt trigger">Schmitt trigger</a> inputs to receive signals from encoders that have <a href="Single-ended_signaling" title="Single-ended signaling">single-ended</a> (e.g., push-pull, open collector) outputs. This type of line receiver inherently rejects low-level noise (by means of its input hysteresis) and protects downstream circuitry from invalid (and possibly destructive) logic signal levels.

</p>

<div class="mw-heading mw-heading4"><h4 id="Differential">Differential</h4></div>

<p>RS-422 line receivers are commonly used to receive signals from encoders that have differential outputs. This type of receiver rejects common-mode noise and converts the incoming differential signals to the single-ended form required by downstream logic circuits.

</p><p>In mission-critical systems, an encoder interface may be required to detect loss of input signals due to encoder power loss, signal driver failure, cable fault or cable disconnect. This is usually accomplished by using enhanced RS-422 line receivers which detect the absence of valid input signals and report this condition via a "signal lost" status output. In normal operation, <a href="Glitch" title="Glitch">glitches</a> (brief pulses) may appear on the status outputs during input state transitions; typically, the encoder interface will filter the status signals to prevent these glitches from being erroneously interpreted as lost signals. Depending on the interface, subsequent processing may include generating an interrupt request upon detecting signal loss, and sending notification to the application for error logging or failure analysis.

</p>

<div class="mw-heading mw-heading3"><h3 id="Clock_synchronization">Clock synchronization</h3></div>

<p>An incremental encoder interface largely consists of <a href="Sequential_logic" title="Sequential logic">sequential logic</a> which is paced by a <a href="Clock_signal" title="Clock signal">clock signal</a>. However, the incoming encoder signals are asynchronous with respect to the interface clock because their timing is determined solely by encoder movement. Consequently, the output signals from the <i>A</i> and <i>B</i> (also <i>Z</i> and <i>alarm</i>, if used) line receivers must be synchronized to the interface clock, both to avoid errors due to <a href="Metastability_(electronics)" title="Metastability (electronics)">metastability</a> and to coerce the signals into the clock domain of the quadrature decoder.<sup id="cite_ref-synchronizers_11-0" class="reference"><a href="#cite_note-synchronizers-11"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>

</p><p>Typically this synchronization is performed by independent, single-signal synchronizers such as the two <a href="Flip-flop_(electronics)" title="Flip-flop (electronics)">flip-flop</a> synchronizer seen here. At very high clock frequencies, or when a very low error rate is needed, the synchronizers may include additional flip-flops in order to achieve an acceptably low <a href="Bit_error_rate" title="Bit error rate">bit error rate</a>.<sup id="cite_ref-SU_sync_12-0" class="reference"><a href="#cite_note-SU_sync-12"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Input_filter">Input filter</h3></div>

<p>In many cases an encoder interface must filter the synchronized encoder signals before further processing them. This may be required in order to reject low-level noise and brief, large-amplitude noise spikes commonly found in motor applications<sup id="cite_ref-agilent_13-0" class="reference"><a href="#cite_note-agilent-13"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup> and, in the case of mechanical-type encoders, to debounce <i>A</i> and <i>B</i> to avoid count errors due to mechanical <a href="Contact_bounce" class="mw-redirect" title="Contact bounce">contact bounce</a>.

</p><p>Hardware-based interfaces often provide programmable filters for the encoder signals, which provide a wide range of filter settings and thus allow them to debounce contacts or suppress transients resulting from noise or slowly slewing signals, as needed. In software-based interfaces, <i>A</i> and <i>B</i> typically are connected to <a href="GPIO" class="mw-redirect" title="GPIO">GPIOs</a> that are sampled (via polling or edge interrupts) and debounced by software.

</p>

<div class="mw-heading mw-heading3"><h3 id="Quadrature_decoder">Quadrature decoder</h3></div>

<p>

</p>

<p>Incremental encoder interfaces commonly use a <b>quadrature decoder</b> to convert the <i>A</i> and <i>B</i> signals into the <i>direction</i> and <i>count enable</i> (clock enable) signals needed for controlling a bidirectional (up- and down-counting) <a href="Synchronous_counter" class="mw-redirect" title="Synchronous counter">synchronous counter</a>.

</p><p>Typically, a quadrature decoder is implemented as a <a href="Finite-state_machine" title="Finite-state machine">finite-state machine</a> (FSM) which simultaneously samples the <i>A</i> and <i>B</i> signals and thus produces amalgamate "AB" samples. As each new AB sample is acquired, the FSM will store the previous AB sample for later analysis. The FSM evaluates the differences between the new and previous AB states and generates <i>direction</i> and <i>count enable</i> signals as appropriate for the detected AB state sequence.<sup id="cite_ref-agilent_13-1" class="reference"><a href="#cite_note-agilent-13"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p>

<caption><b>Quadrature decoder state table</b>

</caption>

<th rowspan="3" style="width:140px">Description</th>

<th colspan="2">AB state</th>

<th colspan="5">Outputs

</th></tr>

<tr>

<th rowspan="2">Previous</th>

<th rowspan="2">Current</th>

<th rowspan="2">ERR

</th></tr>

<tr>

<th>x4

</th></tr>

<tr>

<td rowspan="4" style="text-align:left;vertical-align:top">Moved one increment in "forward" direction<br>(<i>A</i> leads <i>B</i>)</td>

<td rowspan="12">0

</td></tr>

<tr>

<td>0

</td></tr>

<tr>

<td>1

</td></tr>

<tr>

<td>0

</td></tr>

<tr>

<td rowspan="4" style="text-align:left;vertical-align:top">Moved one increment in "reverse" direction<br>(<i>B</i> leads <i>A</i>)</td>

<td rowspan="4">0

</td></tr>

<tr>

<td>1

</td></tr>

<tr>

<td>0

</td></tr>

<tr>

<td>1

</td></tr>

<tr>

<td rowspan="4" style="text-align:left;vertical-align:top">No detected movement</td>

<td rowspan="8">X

</td></tr>

<tr>

<td>01

</td></tr>

<tr>

<td>10

</td></tr>

<tr>

<td>11

</td></tr>

<tr>

<td rowspan="4" style="text-align:left;vertical-align:top">Moved an indeterminate number of increments</td>

<td rowspan="4">1

</td></tr>

<tr>

<td>10

</td></tr>

<tr>

<td>01

</td></tr>

<tr>

<td>00

</td></tr></tbody></table>

<div class="mw-heading mw-heading4"><h4 id="State_transitions">State transitions</h4></div>

<p>In any two consecutive AB samples, the logic level of <i>A</i> or <i>B</i> may change or both levels may remain unchanged, but in normal operation <i>A</i> and <i>B</i> will never both change. In this regard, each AB sample is effectively a two-bit <a href="Gray_code" title="Gray code">Gray code</a>.

</p>

<div class="gallerytext">Movement in forward direction</div>

</li>

<div class="gallerytext">Movement in reverse direction</div>

</li>

<div class="gallerytext">No movement</div>

</li>

<div class="gallerytext">Error</div>

</li>

</ul>

<div class="mw-heading mw-heading5"><h5 id="Normal_transitions">Normal transitions</h5></div>

<p>When only <i>A</i> or <i>B</i> changes state, it is assumed that the encoder has moved one increment of its measurement resolution and, accordingly, the quadrature decoder will assert its <i>count enable</i> output to allow the counts to change. Depending on the encoder's direction of travel (forward or reverse), the decoder will assert or negate its <i>direction</i> output to cause the counts to increment or decrement (or vice versa).

</p><p>When neither <i>A</i> nor <i>B</i> changes, it is assumed that the encoder has not moved and so the quadrature decoder negates its <i>count enable</i> output, thereby causing the counts to remain unchanged.

</p>

<div class="mw-heading mw-heading5"><h5 id="Errors">Errors</h5></div>

<p>If both the <i>A</i> and <i>B</i> logic states change in consecutive AB samples, the quadrature decoder has no way of determining how many increments, or in what direction the encoder has moved. This can happen if the encoder speed is too fast for the decoder to process (i.e., the rate of AB state changes exceeds the quadrature decoder's sampling rate; see <a href="Nyquist_rate" title="Nyquist rate">Nyquist rate</a>) or if the <i>A</i> or <i>B</i> signal is <a href="Noise_(signal_processing)" title="Noise (signal processing)">noisy</a>.

</p><p>In many encoder applications this is a catastrophic event because the counter no longer provides an accurate indication of encoder position. Consequently, quadrature decoders often will output an additional <i>error</i> signal which is asserted when the <i>A</i> and <i>B</i> states change simultaneously. Due to the severity and time-sensitive nature of this condition, the <i>error</i> signal is often connected to an <a href="Interrupt_request" title="Interrupt request">interrupt request</a>.

</p>

<div class="mw-heading mw-heading4"><h4 id="Clock_multiplier">Clock multiplier</h4></div>

<p>A quadrature decoder does not necessarily allow the counts to change for every incremental position change. When a decoder detects an incremental position change (due to a transition of <i>A</i> or <i>B</i>, but not both), it may allow the counts to change or it may inhibit counting, depending on the AB state transition and the decoder's <i>clock multiplier</i>.

</p><p>The clock multiplier of a quadrature decoder is so named because it results in a count rate which is a multiple of the <i>A</i> or <i>B</i> pulse frequency. Depending on the decoder's design, the clock multiplier may be hardwired into the design or it may be run-time configurable via input signals.

</p><p>The clock multiplier value may be one, two or four (typically designated "x1", "x2" and "x4", or "1x", "2x" and "4x").<sup id="cite_ref-machine_design_14-0" class="reference"><a href="#cite_note-machine_design-14"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup> In the case of a x4 multiplier, the counts will change for every AB state change, thereby resulting in a count rate equal to four times the <i>A</i> or <i>B</i> frequency. The x2 and x1 multipliers allow the counts to change on some, but not all AB state changes, as shown in the quadrature decoder state table above (note: this table shows one of several possible implementations for x2 and x1 multipliers; other implementations may enable counting at different AB transitions).

</p>

<div class="mw-heading mw-heading3"><h3 id="Position_reporting">Position reporting</h3></div>

<p>From an application's perspective, the fundamental purpose of an incremental encoder interface is to report position information on demand. Depending on the application, this may be as simple as allowing the computer to read the position counter at any time under program control. In more complex systems, the position counter may be sampled and processed by intermediate state machines, which in turn make the samples available to the computer.

</p>

<div class="mw-heading mw-heading4"><h4 id="Sample_register">Sample register</h4></div>

<p>An encoder interface typically employs a sample register to facilitate position reporting. In the simple case where the computer demands position information under program control, the interface will sample the position counter (i.e., copy the current position counts to the sample register) and then the computer will read the counts from the sample register. This mechanism results in <a href="Atomic_operation" class="mw-redirect" title="Atomic operation">atomic operation</a> and thus ensures the integrity of the sample data, which might otherwise be at risk (e.g., if the sample's word size exceeds the computer's word size).<sup id="cite_ref-sray_1-2" class="reference"><a href="#cite_note-sray-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Triggered_sampling">Triggered sampling</h4></div>

<p>In some cases the computer may not be able to programmatically (via <a href="Programmed_input/output" class="mw-redirect" title="Programmed input/output">programmed I/O</a>) acquire position information with adequate timing precision. For example, the computer may be unable to demand samples on a timely periodic schedule (e.g., for speed measurement) due to software timing variability. Also, in some applications it is necessary to demand samples upon the occurrence of external events, and the computer may be unable to do so in a timely manner. At higher encoder speeds and resolutions, position measurement errors can occur even when interrupts are used to demand samples, because the encoder may move between the time the IRQ is signaled and the sample demand is issued by the interrupt handler.

</p><p>To overcome this limitation, it is common for an incremental encoder interface to implement hardware-triggered sampling, which enables it to sample the position counter at precisely controlled times as dictated by a trigger input signal.<sup id="cite_ref-sray_1-3" class="reference"><a href="#cite_note-sray-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> This is important when the position must be sampled at particular times or in response to physical events, and essential in applications such as multi-axis motion control and CMM, in which the position counters of multiple encoder interfaces (one per axis) must be simultaneously sampled.

</p><p>In many applications the computer must know precisely when each sample was acquired and, if the interface has multiple trigger inputs, which signal triggered the sample acquisition. To satisfy these requirements, the interface typically will include a <a href="Timestamp" title="Timestamp">timestamp</a> and trigger information in every sample.

</p>

<div class="mw-heading mw-heading5"><h5 id="Event_notification">Event notification</h5></div>

<p>Sampling triggers are often asynchronous with respect to software execution. Consequently, when the position counter is sampled in response to a trigger signal, the computer must be notified (typically via <a href="Interrupt" title="Interrupt">interrupt</a>) that a sample is available. This allows the software to be <a href="Event-driven_programming" title="Event-driven programming">event-driven</a> (vs. <a href="Polling_(computer_science)" title="Polling (computer science)">polled</a>), which facilitates responsive system behavior and eliminates polling overhead.

</p>

<div class="mw-heading mw-heading5"><h5 id="Sample_FIFO">Sample FIFO</h5></div>

<p>Consecutive sampling triggers may occur faster than the computer can process the resulting samples. When this happens, the information in the sample register will be overwritten before it can be read by the computer, resulting in data loss. To avoid this problem, some incremental encoder interfaces provide a <a href="FIFO_(computing_and_electronics)" title="FIFO (computing and electronics)">FIFO</a> buffer for samples.<sup id="cite_ref-sray_1-4" class="reference"><a href="#cite_note-sray-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> As each sample is acquired, it is stored in the FIFO. When the computer demands a sample, it is allowed to read the oldest sample in the FIFO.

</p>

<div class="mw-heading mw-heading2"><h2 id="Notes">Notes</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

<li id="cite_note-abs-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-abs_5-0">^</a></b></span> <span class="reference-text">An encoder's <i>A</i> and <i>B</i> output signals do not indicate absolute position. The absolute position is only known after referencing the index signal or homing. However, the <i>index</i> signal, when present and asserted, indicates the encoder is located at its reference position, which in some applications may be an absolute position.</span>

</li>

<li id="cite_note-jam-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-jam_8-0">^</a></b></span> <span class="reference-text">In the context of synchronous digital counters, "jamming" is the act of changing the stored counts to a specific value. The value is applied to the counter's parallel data inputs and the counter's Load Enable (or equivalent) input is asserted to invoke the counts change. During this operation, normal counting is momentarily disabled.</span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFSensoray" class="citation web cs1">Sensoray. <a rel="nofollow" class="external text" href="http://www.sensoray.com/support/appnotes/encoders.htm">"Introduction to Incremental Encoders"</a><span class="reference-accessdate">. Retrieved <span class="nowrap">18 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-craig-2"><span class="mw-cite-backlink">^ <a href="#cite_ref-craig_2-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-craig_2-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-craig_2-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-craig_2-3"><sup><i><b>d</b></i></sup></a> <a href="#cite_ref-craig_2-4"><sup><i><b>e</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFCraig" class="citation web cs1">Craig, K. <a rel="nofollow" class="external text" href="http://engineering.nyu.edu/mechatronics/Control_Lab/Criag/Craig_RPI/SenActinMecha/S&A_Optical_Encoders.pdf">"Optical Encoders"</a> <span class="cs1-format">(PDF)</span><span class="reference-accessdate">. Retrieved <span class="nowrap">25 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-epc-3"><span class="mw-cite-backlink">^ <a href="#cite_ref-epc_3-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-epc_3-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-epc_3-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://encoder.com/core/files/encoder/uploads/files/WP-2011.pdf">"The Basics of How an Encoder Works"</a> <span class="cs1-format">(PDF)</span>. Encoder Products Company<span class="reference-accessdate">. Retrieved <span class="nowrap">23 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-ics-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-ics_4-0">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://ics.as/wp-content/uploads/2013/05/Hengstler-Encoder-basics.pdf">"Encoder Basics"</a> <span class="cs1-format">(PDF)</span>. ICS A/S.</cite></span>

</li>

<li id="cite_note-nasa-6"><span class="mw-cite-backlink">^ <a href="#cite_ref-nasa_6-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-nasa_6-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-nasa_6-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-nasa_6-3"><sup><i><b>d</b></i></sup></a> <a href="#cite_ref-nasa_6-4"><sup><i><b>e</b></i></sup></a></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://irtfweb.ifa.hawaii.edu/~tcs3/tcs3/0306_conceptual_design/Docs/05_Encoders/encoder_primer.pdf">"Encoder Primer"</a> <span class="cs1-format">(PDF)</span>. <i>NASA Infrared Telescope Facility (IRTF)</i>. Institute for Astronomy, University of Hawaii<span class="reference-accessdate">. Retrieved <span class="nowrap">17 August</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-epc2-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-epc2_7-0">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://encoder.com/blog/white-papers-other-resources/3-steps-to-specifying-the-correct-encoder-output-type/">"3 Steps to Specifying the Correct Encoder Output Type"</a>. Encoder Products<span class="reference-accessdate">. Retrieved <span class="nowrap">20 August</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-9">^</a></b></span> <span class="reference-text"><cite id="CITEREFCollins" class="citation web cs1">Collins, Danielle. <a rel="nofollow" class="external text" href="https://www.motioncontroltips.com/how-are-encoders-used-for-speed-measurement/">"How are encoders used for speed measurement?"</a>. Design World<span class="reference-accessdate">. Retrieved <span class="nowrap">22 September</span> 2020</span>.</cite></span>

</li>

<li id="cite_note-petrella-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-petrella_10-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFPetrellaTursiniPerettiZigliotto" class="citation web cs1">Petrella, Roberto; Tursini, Marco; Peretti, Luca; Zigliotto, Mauro. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20210416135625/http://www.diegm.uniud.it/petrella/Azionamenti%20Elettrici%20II/Tesine/Petrella%20et%20al.%20-%20Speed%20Measurement%20Algorithms%20for%20Low-Resolution%20Incremental%20Encoder%20Equipped%20Drives_a%20Comparative%20Analysis.pdf">"Speed Measurement Algorithms for Low-Resolution Incremental Encoder Equipped Drives: a Comparative Analysis"</a> <span class="cs1-format">(PDF)</span>. Archived from <a rel="nofollow" class="external text" href="http://www.diegm.uniud.it/petrella/Azionamenti%20Elettrici%20II/Tesine/Petrella%20et%20al.%20-%20Speed%20Measurement%20Algorithms%20for%20Low-Resolution%20Incremental%20Encoder%20Equipped%20Drives_a%20Comparative%20Analysis.pdf">the original</a> <span class="cs1-format">(PDF)</span> on 16 April 2021<span class="reference-accessdate">. Retrieved <span class="nowrap">22 September</span> 2020</span>.</cite></span>

</li>

<li id="cite_note-synchronizers-11"><span class="mw-cite-backlink"><b><a href="#cite_ref-synchronizers_11-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFGinosar" class="citation web cs1">Ginosar, Ran. <a rel="nofollow" class="external text" href="https://webee.technion.ac.il/~ran/papers/Metastability-and-Synchronizers.IEEEDToct2011.pdf">"Metastability and Synchronizers: A Tutorial"</a> <span class="cs1-format">(PDF)</span>. Israel Institute of Technology<span class="reference-accessdate">. Retrieved <span class="nowrap">21 January</span> 2020</span>.</cite></span>

</li>

<li id="cite_note-SU_sync-12"><span class="mw-cite-backlink"><b><a href="#cite_ref-SU_sync_12-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFDonohue" class="citation web cs1">Donohue, Ryan. <a rel="nofollow" class="external text" href="https://web.stanford.edu/class/ee183/handouts/synchronization_pres.pdf">"Synchronization in Digital Logic Circuits"</a> <span class="cs1-format">(PDF)</span>. Stanford University<span class="reference-accessdate">. Retrieved <span class="nowrap">21 January</span> 2020</span>.</cite></span>

</li>

<li id="cite_note-agilent-13"><span class="mw-cite-backlink">^ <a href="#cite_ref-agilent_13-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-agilent_13-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://groups.csail.mit.edu/drl/courses/cs54-2001s/pdf/hctl2000.pdf">"Quadrature Decoder/Counter Interface ICs"</a> <span class="cs1-format">(PDF)</span>. Agilent Technologies<span class="reference-accessdate">. Retrieved <span class="nowrap">20 August</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-machine_design-14"><span class="mw-cite-backlink"><b><a href="#cite_ref-machine_design_14-0">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://www.machinedesign.com/archive/addressing-encoder-error">"Addressing encoder error"</a>. Machine Design<span class="reference-accessdate">. Retrieved <span class="nowrap">20 August</span> 2018</span>.</cite></span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><span class="noviewer" typeof="mw:File"></span> Media related to <a href="https://commons.wikimedia.org/wiki/Category:Incremental_encoders" class="extiw external" title="commons:Category:Incremental encoders">Incremental encoders</a> at Wikimedia Commons</li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-10" href="https://en.wikipedia.org/wiki/?title=Incremental_encoder&oldid=1299764622">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>